Machine learning artificial intelligence system for predicting hours of operation

ABSTRACT

An artificial intelligence system for communicating predicted hours of operation to a client device. The system may include a processor in communication with a client device and a database; and a storage medium storing instructions. When executed, the instructions in the storage medium configure the processor to: receive, from the client device, a request for hours of operation of a merchant, the request specifying a day of the week; obtain, from the database in response to the request, a set of credit card authorizations associated with the merchant; determine a selected day authorizations subset by selecting, from the set of credit card authorizations, credit card authorizations issued on the specified day of the week; generate a posted transaction array based on the selected day authorizations subset, the posted transaction array may include a plurality of time intervals and numbers of transactions for the time intervals; generate a predictions list based on the posted transaction array, the predictions list including the time intervals and prediction indications for the time intervals; and communicate the predictions list to the client device.

RELATED APPLICATIONS

This application is related to U.S. Provisional Patent Application No.62/487,529, filed Apr. 20, 2017. The contents of this application areincorporated in their entirety by reference.

TECHNICAL FIELD

The present disclosure relates generally to a machine learningartificial intelligence system for modeling hours of operation, and moreparticularly, to an artificial intelligence system to model a merchant'shours of operation using credit card authorization data and machinelearning.

BACKGROUND

Consumers often prefer to know whether and when business establishmentsare open for business, to allow them organize and plan their ownschedules. There is no central repository, however, as to when allbusinesses are open.

When a credit card is used to pay for a product, the merchant submits arequest to an acquirer bank. The acquirer bank then sends a request toan issuer bank that authorizes or declines the transaction. If thetransaction is approved, the issuer bank provides an authorization codeto the acquirer bank, which notifies the merchant to complete thetransaction. Each request and authorization involved in this processincludes data about the merchant, the consumer, and the transaction. Forexample, credit card authorizations may have time stamps, a merchantidentifier, a transaction amount, and an account number, among otherthings. Therefore, credit card authorizations may be used to makeinferences about the merchant, the consumer, or the transaction.Particularly nowadays, when millions of credit card transactions arerecorded every day, statistical methods can be used to analyze creditcard authorization data, make accurate inferences, and observe trends.

Credit card authorizations are normally generated when a merchant isopen for operation and serving customers. Typically, merchants submitthe credit card authorization requests to the acquirer bank concurrentlywith a consumer making a purchase. Therefore, credit card authorizationscan be used to infer whether the merchant is serving customers and isthus “open.” For example, a restaurant may normally issue multiplecredit card authorization requests between 11 am and 1 pm when it servescustomers during lunch. Thus, it is possible to infer that therestaurant is open between 11 am and 1 pm, based on credit cardauthorization requests. On the other hand, the same restaurant may notissue any credit card authorization requests between 1 am and 2 am.Thus, it is possible to infer that the restaurant is “closed” between 1am and 2 am. Therefore, analysis of credit card authorization data canbe used to predict a merchant's hours of operation.

However, making accurate predictions of merchant's hours of operationbased on credit card authorization request data alone may be challengingfor several reasons. First, there may be an imperfect correlationbetween credit card authorization data and hours of operation. Forexample, a restaurant may open at 10 am but only start issuing creditcard authorizations at 10:30 am, when the first customer finishes his orher meal and pays. In this example, the correlation between hours ofoperation and authorization requests is offset and may lead toprediction errors. Second, data repositories of credit cardauthorizations may store millions of authorizations per day. The largequantity and variety of authorization formats and merchant practices maymake it difficult to effectively process the authorization data. Third,the correlations between credit card authorizations and hours ofoperation can be dynamic and may be influenced by externalities. Forexample, the correlation between authorizations and hours of operationmay be influenced by merchant location, season, and/or business type.For instance, a merchant may have summer hours of operation that aredifferent to the winter hours of operation. These are some of thedifficulties that make prediction of hours of operation challenging, butother variables also affect correlations and predictions.

The disclosed machine learning artificial intelligence system andmodeling methods address one or more of the problems set forth aboveand/or other problems in the prior art.

SUMMARY

One aspect of the present disclosure is directed to an artificialintelligence system for communicating predicted hours of operation to aclient device. The system may include a processor in communication witha client device and a database; and a storage medium storinginstructions. When executed, the instructions in the storage mediumconfigure the processor to: receive, from the client device, a requestfor hours of operation of a merchant, the request specifying a day ofthe week; obtain, from the database in response to the request, a set ofcredit card authorizations associated with the merchant; determine aselected day authorizations subset by selecting, from the set of creditcard authorizations, credit card authorizations issued on the specifiedday of the week; generate a posted transaction array based on theselected day authorizations subset, the posted transaction array mayinclude a plurality of time intervals and numbers of transactions forthe time intervals; generate a predictions list based on the postedtransaction array, the predictions list including the time intervals andprediction indications for the time intervals; and communicate thepredictions list to the client device.

Another aspect of the present disclosure is directed a non-transitorycomputer-readable medium storing instructions that, when executed by aprocessor, cause the processor to operate an artificial intelligencesystem for communicating predicted hours of operation to a clientdevice. The instructions may include receiving, from a client device, arequest for hours of operation of a merchant, the request specifying aday of the week; obtaining, from a database in response to the request,a set of credit card authorizations associated with the merchant;determining a selected day authorizations subset by selecting, from theset of credit card authorizations, credit card authorizations issued onthe specified day of the week; generating a posted transaction arraybased on the selected day authorizations subset, the posted transactionarray including a plurality of time intervals and numbers oftransactions for the time intervals; generating a predictions list basedon the posted transaction array, the predictions list including the timeintervals and prediction indications for the time intervals; andcommunicating the predictions list to the client device.

Yet another aspect of the present disclosure is directed to anartificial intelligence method for communicating hours of operation to aclient device, the method including: receiving, from a client device, arequest for hours of operation of a merchant, the request specifying aday of the week; obtaining, from a database in response to the request,a set of credit card authorizations associated with the merchant;determining a selected day authorizations subset by selecting, from theset of credit card authorizations, credit card authorizations issued onthe specified the day of the week; generating a posted transaction arraybased on the selected day authorizations subset, the posted transactionarray including a plurality of time intervals and numbers oftransactions for the time intervals; generating a predictions list basedon the posted transaction array, the predictions list including the timeintervals and prediction indications for the time intervals; andcommunicating the predictions list to the client device.

Another aspect of the present disclosure is directed to an artificialintelligence system for generating an hours of operation model. Thesystem may include a processor in communication with a prediction systemand a database; and a storage medium. The storage medium may includeinstructions that, when executed, configure the processor to: receive,from a prediction system, a request for an hours of operation model formerchants; determine a merchant classification based on metadataassociated with the merchants; obtain, from a ground truth analyzer,ground truth data associated with the merchant classification; obtain,from the database, a set of credit card authorizations associated withthe merchant classification; generate input model features based on theset of credit card authorizations; generate a training data set and avalidation data set based on the ground truth data and the set of creditcard authorizations; determine an hours of operation model based ontraining data set and the input model features; determine a performanceof the hours of operation model based on the validation data set; andcommunicate the hours of operation model for the merchant to theprediction system.

Yet another aspect of the present disclosure is directed to anon-transitory computer-readable medium storing instructions that, whenexecuted by a processor, cause the processor to operate an artificialintelligence system for generating an hours of operation model. Theinstructions may include receiving, from a prediction system, a requestfor an hours of operation model for merchants; determining a merchantclassification based on metadata associated with the merchants;obtaining, from a ground truth analyzer, ground truth data associatedwith the merchant classification; obtaining, from the database, a set ofcredit card authorizations associated with the merchant classification;generating input model features based on the set of credit cardauthorizations; generating a training data set and a validation data setbased on the ground truth data and the set of credit cardauthorizations; determining an hours of operation model based ontraining data set and the input model features; determining accuracy ofthe hours of operation model based on the validation data set; andcommunicating the hours of operation model for the merchant to theprediction system.

Another aspect of the present disclosure is directed to an artificialintelligence method for generating an hours of operation model for aprediction system. The method may include receiving, from a predictionsystem, a request for an hours of operation model for merchants;determining a merchant classification based on metadata associated withthe merchants; obtaining, from a ground truth analyzer, ground truthdata associated with the merchant classification; obtaining, from thedatabase, a set of credit card authorizations associated with themerchant classification; generating input model features based on theset of credit card authorizations generating a training data set and avalidation data set based on the ground truth data and the set of creditcard authorizations; determining an hours of operation model based ontraining data set and input model features; determining a performance ofthe hours of operation model based on the validation data set; andcommunicating the hours of operation model for the merchant to theprediction system.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute apart of this specification, illustrate disclosed embodiments and,together with the description, serve to explain the disclosedembodiments. In the drawings:

FIG. 1 is a block diagram of an exemplary system, in accordance withdisclosed embodiments.

FIG. 2 is a block diagram of an exemplary prediction system, inaccordance with disclosed embodiments.

FIG. 3 is a block diagram of an exemplary model generator, in accordancewith disclosed embodiments.

FIG. 4 is a block diagram of an exemplary database, in accordance withdisclosed embodiments.

FIG. 5 is a block diagram of an exemplary client device, in accordancewith disclosed embodiments.

FIG. 6 is an exemplary flow chart illustrating a prediction process, inaccordance with disclosed embodiments.

FIG. 7 is an exemplary flow chart illustrating a prediction listgeneration process, in accordance with disclosed embodiments.

FIG. 8 is an exemplary flow chart illustrating a posted transactionarray generation process, in accordance with disclosed embodiments.

FIG. 9 is an exemplary flow chart illustrating a prediction modelgeneration process, in accordance with disclosed embodiments.

FIG. 10A is an exemplary posted transaction array, in accordance withdisclosed embodiments.

FIG. 10B is an exemplary prediction list, in accordance with disclosedembodiments.

FIG. 11 is a graph of an exemplary calculation of accuracy as a functionof time intervals, in accordance with disclosed embodiments.

FIG. 12 is a group of exemplary graphs presenting ground truth andprediction values as a function of time intervals for control examples,according with disclosed embodiments.

FIG. 13 is a group of exemplary graphs presenting ground truth andprediction values as a function of time intervals for testing examples,according with disclosed embodiments.

DETAILED DESCRIPTION

The disclosure is generally directed to a machine learning artificialintelligence system for predicting hours of operation and communicatingthem to a client device. The artificial intelligence system may model amerchant's hours of operation using credit card authorization data. Insome embodiments, a client device may present to a prediction system arequest for a merchant's hours of operation. The prediction system mayanalyze credit card authorization data associated with the merchantusing prediction models. The prediction models may be generated usingmachine learning algorithms that study training data sets that associatemerchants with corresponding “ground truth,” that is, informationprovided by direct observation as opposed to information provided byinference. The machine learning algorithms may update and tailor theprediction models based on the client request. The prediction system mayoutput a prediction of hours of operation based on the analysis ofcredit card authorizations. In some embodiments, the prediction systemmay be coupled with databases that store credit card authorizations anduse data processing methods to curate information and facilitate dataanalysis. In other embodiments, the prediction system may improveaccuracy by using iterative methods in which multiple prediction modelsare generated and then aggregated. In yet other embodiments, theprediction system may be hardware configured to efficiently conductfiltering, sorting, and parallel calculation tasks to improve computingtime and cost.

Reference will now be made in detail to the disclosed embodiments,examples of which are illustrated in the accompanying drawings.

FIG. 1 is a block diagram of an exemplary system 100, in accordance withdisclosed embodiments. System 100 may be used to predict a merchant'shours of operation, in accordance with disclosed embodiments. System 100may include a prediction system 110, a model generator 120, financialservices 130, online resources 140, client devices 150, merchants 160,and databases 180. In some embodiments, as shown in FIG. 1, eachcomponent of system 100 may be connected to a network 170. However, inother embodiments components of system 100 may be connected directlywith each other, without network 170.

Financial services 130 may be a system associated with a financialservice provider, which may be an entity providing financial services.For example, financial services 130 may be associated with a bank, acredit card issuer, or other type of financial service entity thatgenerates, provides, manages, and/or maintains financial serviceaccounts. Financial services 130 may store information about accountsand include, for example, credit card accounts, loan accounts, checkingaccounts, savings accounts, reward accounts, loyalty program accounts,debit card accounts, cryptocurrency accounts, and/or other types offinancial service accounts known to those skilled in the art. Financialservices 130 may include infrastructure and components that areconfigured to generate and/or provide financial service accounts such ascredit card accounts, checking accounts, debit card accounts, loyalty orreward programs, lines of credit, and the like. Financial services 130may authorize or decline credit card authorization requests and mayissue authorization codes.

Online resources 140 may include one or more servers or storage servicesprovided by an entity such as a provider of website hosting, networking,cloud, or backup services. In some embodiments, online resources 140 maybe associated with hosting services or servers that store web pages formerchants 160. In other embodiments, online resources 140 may beassociated with a cloud computing service such as Microsoft Azure™ orAmazon Web Services™. In yet other embodiments, online resources 140 maybe associated with a messaging service, such as, for example, Apple PushNotification Service, Azure Mobile Services, or Google Cloud Messaging.In such embodiments, online resources 140 may handle the delivery ofmessages and notifications related to functions of the disclosedembodiments, such as credit card authorization creation, credit cardauthorization alerts, and/or completion messages and notifications.

Client devices 150 may include one or more computing devices configuredto perform one or more operations consistent with disclosed embodiments.For example, client devices 150 may include a desktop computer, alaptop, a server, a mobile device (e.g., tablet, smart phone, etc.), agaming device, a wearable computing device, or other type of computingdevice. Client devices 150 may include one or more processors configuredto execute software instructions stored in memory, such as memoryincluded in client devices 150. Client devices 150 may include softwarethat when executed by a processor performs known Internet-relatedcommunication and content display processes. For instance, clientdevices 150 may execute browser software that generates and displaysinterfaces including content on a display device included in, orconnected to, client devices 150. Client devices 150 may executeapplications that allows client devices 150 to communicate withcomponents over network 170, and generate and display content ininterfaces via display devices included in client devices 150. Thedisclosed embodiments are not limited to any particular configuration ofclient devices 150. For instance, a client device 150 may be a mobiledevice that stores and executes mobile applications that providefunctions offered by prediction system 110 and/or online resources 140,such as providing information about merchants 160. In certainembodiments, client devices 150 may be configured to execute softwareinstructions relating to location services, such as GPS locations. Forexample, client devices 150 may be configured to determine a geographiclocation and provide location data and time stamp data corresponding tothe location data.

Merchants 160 may include one or more entities that provide goods,services, and/or information, such as a retailer (e.g., Macy's®,Target®, etc.), a grocery store, an entertainment venue (e.g. cinema,theater, museum, etc.), a service provider (e.g., utility company,etc.), a restaurant, a bar, a non-profit organization (e.g., ACLU™AARP®, etc.) or other type of entity that provides goods, services,and/or information that consumers (e.g., end-users or other businessentities) may purchase, consume, use, etc. Merchants 160 are not limitedto entities associated with any particular business, specific industry,or distinct field.

Merchants 160 may include one or more computing systems, such asservers, that are configured to execute stored software instructions toperform operations associated with a merchant, including one or moreprocesses associated with processing purchase transactions, generatingtransaction data, generating product data (e.g., stock keeping unit(SKU) data) relating to purchase transactions, etc.

In some embodiments, merchants 160 may be brick-and-mortar locationsthat a consumer may physically visit and purchase goods and services.Such physical locations may include merchant paying system 162, whichmay include computing devices that perform financial servicetransactions with consumers (e.g., Point-of-Sale (POS) terminal(s),kiosks, etc.). Merchant paying system 162 may include one or morecomputing devices configured to perform operations consistent withfacilitating purchases at merchants 160. Merchant paying system 162 mayalso include back- and/or front-end computing components that store dataand execute software instructions to perform operations consistent withdisclosed embodiments, such as computers that are operated by employeesof the merchant (e.g., back office systems, etc.).

While merchant paying system 162 is shown within merchants 160 in FIG.1, in some embodiments merchant paying system 162 may be separated frommerchant 160. For example, merchant paying system 162 may be a differententity that services merchants 160. In such embodiments, merchants 160may provide goods and/or services via online solutions. Merchants 160may sell goods via a website to market, sell, and process onlinetransactions. Then, merchant paying system 162 may provide aninfrastructure for online payments.

In some embodiments, merchant paying system 162 may include apoint-of-sale terminal 166. In particular, a financial card purchase maybe carried out by presenting a financial card at a point-of-saleterminal 166. Data associated with the financial card may be provided topayment processor 164, and payment processor 164 may process payment thepurchase. For example, payment processor 164 may generate the creditcard authorization and include the time stamp and information about themerchant.

For each purchase, merchant paying system 162 may collect and/ormaintain data identifying the financial card that has been used to makethe purchases at merchants 160. Additionally, merchant paying system 162may collect and/or maintain data identifying a customer associated withthe financial card and/or data identifying a date on which the purchasewas made. The merchant paying system 162 may collect and/or maintainother data as well. Data collected and/or maintained by merchant payingsystem 162 may be provided to databases 180, model generator 120, and/orprediction system 110.

In some embodiments, payment processor 164 may be a device configured tocollect credit card information and issue credit card authorizations.Payment processor 164 may be a magnetic stripe reader that collectscredit card information and connects with a credit card network. In suchembodiments, payment processor 164 may include software to appendinformation to the credit card authorization or issue new notificationsthat facilitate hours-of-operation modeling. For example, paymentprocessor 164 may include a program to flag a credit card authorization,append a time stamp based on a location code (e.g. Zip Code™, andspecify the merchant's address.

In some embodiments, to simplify the collection of data, paymentprocessor 164 may also be connected to databases 180. In suchembodiments, payment processor 164 may include a communication devicethat sends information to both financial services 130 (i.e., acquirerbank) and databases 180. In such embodiments, when payment processor 164is used to complete a credit card transaction, payment processor 164 mayissue a simplified authorization with only time, date, and location. Thesimplified authorization may then be transmitted to databases 180 and belater used by prediction system 110 or model generator 120. Thesimplified authorization improves transmission rates and facilitatesselection of authorizations for modeling hours of operation. Forinstance, simplified credit card authorization records may be easier tofilter and sort. In yet other embodiments, payment processor 164 may addinformation to the credit card authorization for the prediction model.For example, payment processor 164 may append local time and merchant IDto the authorization before sending it to databases 180 and/or financialservices 130.

Databases 180 may include one or more computing devices configured withappropriate software to perform operations consistent with providingprediction system 110 and model generator 120 with data associated withmerchants 160. Databases 180 may include, for example, Oracle™databases, Sybase™ databases, or other relational databases ornon-relational databases, such as Hadoop™ sequence files, HBase™, orCassandra™ Database(s) 180 may include computing components (e.g.,database management system, database server, etc.) configured to receiveand process requests for data stored in memory devices of thedatabase(s) and to provide data from the database(s).

Data associated with merchants 160 may include, for example, historicaldata identifying authorizations associated with financial cards used tomake purchases at merchants 160. A financial card may represent anymanner of making a purchase at merchants 160. A financial card may be,for example, a financial services product associated with a financialservice account, such as a bank card, key fob, or smartcard. Forexample, a financial card may comprise a credit card, debit card,loyalty card, or other similar financial services product. In someembodiments, a financial card may comprise a digital wallet or paymentapplication. Thus, a financial card is not limited to a specificphysical configuration and may be provided in any form capable ofperforming the functionality of the disclosed embodiments. In someembodiments, a financial card may include or be included in a mobiledevice; a wearable item, including jewelry, a smart watch, or any otherdevice suitable for carrying or wearing on a customer's person. Otherfinancial cards are possible as well. Data identifying financial cardsused to make purchases at merchants 160 may include, for example, dateson which the purchases were made at merchants 160 and identification ofcustomers associated with the financial cards.

Data associated with merchants 160 may further include, for example,data identifying financial cards, dates on which credit cardauthorizations were issued, and times of the day when credit cardauthorizations were issued. In some embodiments, data associated withmerchants 160 may further include data describing merchant paying system162. Data describing merchants 160 may include, for example, dataidentifying a brand or operator of merchant paying system 162, dataidentifying a merchant type associated with merchants 160 (e.g.,restaurant, grocery, hair cutter, clothing retailer, etc.), dataidentifying a geographic location of merchants 160 (e.g., Zip Code™,county, state, etc.), data describing a point-of-sale terminal 166 usedat merchants 160 (e.g., terminal manufacturer, terminal hardware,terminal software, etc.), and/or data describing a payment processor 164used by merchants 160 (e.g., processor operator, processor hardware,processor software, etc.). The data describing payment processor 164used by the merchants 160 may include an indication that a reducedauthorization is appended to the authorization.

While databases 180 are shown separately, in some embodiments databases180 may be included in or otherwise related to one or more of predictionsystem 110, model generator 120, financial services 130, and onlineresources 140.

Databases 180 may be configured to collect and/or maintain the dataassociated with merchants 160 and provide it to the prediction system110, model generator 120, financial services 130, and client devices150. Databases 180 may collect the data from a variety of sources,including, for instance, merchants 160, payment processor 164, modelgenerator 120, and/or third-party systems (not shown). Other sources ofdata associated with merchants 160 are possible as well. Databases 180are further described below in connection with FIG. 4.

Model generator 120 may include one or more computing systems configuredto generate prediction models to estimate hours of operations usingcredit card authorizations. Model generator 120 may receive or obtaininformation from databases 180, merchants 160, online resources 140, andfinancial services 130. For example, model generator 120 may receivecredit card authorization records from databases 180 and merchants 160.Model generator 120 may also receive information about hours ofoperation from online resources 140 and financial services 130.

In some embodiments, model generator 120 may receive requests fromprediction system 110. As a response to the request, model generator 120may generate one or more prediction models. Prediction models mayinclude statistical algorithms that are used to determine theprobability of an outcome, given a set amount of input data. Forexample, prediction models may include regression models that estimatethe relationships among input and output variables. Prediction modelsmay also sort elements of a dataset using one or more classifiers todetermine the probability of a specific outcome. Prediction models maybe parametric, non-parametric, and/or semi-parametric models.

In some embodiments, prediction models may cluster points of data infunctional groups such as “random forests.” Random Forests may comprisecombinations of decision tree predictors. (Decision trees may comprise adata structure mapping observations about something, in the “branch” ofthe tree, to conclusions about that thing's target value, in the“leaves” of the tree.) Each tree may depend on the values of a randomvector sampled independently and with the same distribution for alltrees in the forest. Prediction models may also include artificialneural networks. Artificial neural networks may model input/outputrelationships of variables and parameters by generating a number ofinterconnected nodes which contain an activation function. Theactivation function of a node may define a resulting output of that nodegiven an argument or a set of arguments. Artificial neural networks maygenerate patterns to the network via an ‘input layer’, whichcommunicates to one or more “hidden layers” where the system determinesregressions via a weighted connections. Prediction models mayadditionally or alternatively include classification and regressiontrees, or other types of models known to those skilled in the art. Modelgenerator 120 may submit models to predict hours of operation. Togenerate prediction models, model generator 120 may analyze informationapplying machine-learning methods. Model generator 120 may communicateback with prediction system 110 via network 170 or other communicationavenues. Model generator 120 is further described below in connectionwith FIG. 3.

Prediction system 110 may include one or more computing systemsconfigured to perform one or more operations consistent with modelingthe hours of operation of merchants 160. In some embodiments, predictionsystem 110 may receive a request for information. Prediction system 110may receive the request directly from client devices 150. Alternatively,prediction system may receive the request from other components ofsystem 100. For example, client devices 150 may send requests to onlineresources 140, which then sends requests to prediction system 110. Therequest may specify a merchant and a day of the week. Additionally, insome embodiments the request may specify a date. In other embodiments,the request may be done for a plurality of merchants and a minimumprediction confidence.

As a response to information requests, prediction system 110 may requestprediction models from model generator 120. The request may includeinformation about the merchant. The request may additionally specify aday of the week. In addition, prediction system 110 may retrieveinformation from databases 180.

Prediction system 110 may generate a prediction result based on theinformation received from the client request and transmit theinformation to the client device. Prediction system 110 may plot theprediction result. Prediction system 110 is further described below inconnection with FIG. 2.

FIG. 1 shows prediction system 110 and model generator 120 as adifferent components. However, prediction system 110 and model generator120 may be implemented in the same computing system. For example,prediction system 110 and model generator 120 may be embodied in asingle server.

Network 170 may be any type of network configured to providecommunications between components of system 100. For example, network170 may be any type of network (including infrastructure) that providescommunications, exchanges information, and/or facilitates the exchangeof information, such as the Internet, a Local Area Network, near fieldcommunication (NFC), optical code scanner, or other suitableconnection(s) that enables the sending and receiving of informationbetween the components of system 100. In other embodiments, one or morecomponents of system 100 may communicate directly through a dedicatedcommunication link(s).

It is to be understood that the configuration and boundaries of thefunctional building blocks of system 100 have been defined herein forthe convenience of the description. Alternative boundaries can bedefined so long as the specified functions and relationships thereof areappropriately performed. Alternatives (including equivalents,extensions, variations, deviations, etc., of those described herein)will be apparent to persons skilled in the relevant art(s) based on theteachings contained herein. Such alternatives fall within the scope andspirit of the disclosed embodiments.

FIG. 2 is a block diagram of an exemplary prediction system, inaccordance with disclosed embodiments. Prediction system 110 may includea communication device 212, a prediction memory 220, and one or moreprediction processors 208. Prediction memory 220 may include predictionprograms 222 and prediction data 224. Prediction processor 230 mayinclude authorization selector 232, authorization aggregator 234, andprediction engine 236.

In some embodiments, prediction system 110 may take the form of aserver, general purpose computer, mainframe computer, or any combinationof these components. Other implementations consistent with disclosedembodiments are possible as well.

Communication device 210 may be configured to communicate with one ormore databases, such as databases 180 described above. In particular,communication device 210 may be configured to receive from the databasedata associated with merchants 160. In addition, communication device210 may be configured to communicate with other components as well,including, for example, merchant payment system 166 and model generator120.

Communication device 210 may include, for example, one or more digitaland/or analog devices that allow communication device 210 to communicatewith and/or detect other components, such as a network controller and/orwireless adaptor for communicating over the Internet. Otherimplementations consistent with disclosed embodiments are possible aswell.

Prediction memory 220 may include one or more storage devices configuredto store instructions used by prediction processor 230 to performfunctions related to disclosed embodiments. For example, predictionmemory 220 may store software instructions, such as prediction program222, that may perform one or more operations when executed by predictionprocessor 230. The disclosed embodiments are not limited to separateprograms or computers configured to perform dedicated tasks. Forexample, prediction memory 220 may include a single prediction program222 that performs the functions of prediction system 110, or predictionprogram 222 may comprise multiple programs. Prediction memory 220 mayalso store prediction data 224 that is used by prediction program(s)222.

In certain embodiments, prediction memory 220 may store sets ofinstructions for carrying out processes to model hours of operation,generate a prediction list, and/or generate a posted transaction array,described below in connection with FIGS. 6-8. In certain embodiments,prediction memory 220 may store sets of instructions for generatinggraphical objects, such as the ones described below in connection withFIGS. 11-13. Other instructions are possible as well. In general,instructions may be executed by prediction processor 230 to perform oneor more processes consistent with disclosed embodiments.

In some embodiments, prediction processor 230 may include one or moreknown processing devices, such as, but not limited to, microprocessorsfrom the Pentium™ or Xeon™ family manufactured by Intel™, the Turion™family manufactured by AMD™, or any of various processors from othermanufacturers. However, in other embodiments, prediction processor 230may be a plurality of devices coupled and configured to performfunctions in accordance with the disclosure.

Prediction processor 230 may include an authorization selector 232, anauthorization aggregator 234, and a prediction engine 236. In someembodiments, prediction processor 230 may execute software to performfunctions associated with each component of prediction processor 230. Inother embodiments, each component of prediction processor 230 may be anindependent device. In such embodiments, each component may be hardwareconfigured to specifically process data or perform operations associatedwith modeling hours of operation, generating prediction models and/orhandling large data sets. For example, authorization selector 232 may bea field-programmable gate array (FPGA), authorization aggregator 234 maybe a Graphics processing unit (GPU), and prediction engine 236 may be acentral processing unit (CPU). Other hardware combinations are alsopossible. In yet other embodiments, combinations of hardware andsoftware may be used to implement prediction processor 230.

Authorization selector 232 may select credit card authorizations fromdatabases 180 based on parameters such as a day of the week, a specificmerchant, and/or a merchant identification. For example, communicationdevice 210 may receive from databases 180 a set of credit cardauthorizations. The set of credit card authorizations may includemultiple credit card authorizations recorded during a selectable orvariable period of time. For example, the period of time may be selectedto be at least one year so the set of credit card authorizationsrepresent every season throughout the year. Authorization selector 232may select a subset of credit card authorizations that are associatedwith a merchant by filtering the data set. In some embodiments,authorization selector 232 may employ techniques such as the pigeonholeprinciple, hierarchical verification, and the PEX algorithm, to filterand select credit card authorizations. In some embodiments,authorization selector 232 may compare specific fields of the creditcard authorization to accept or discard authorizations. For example,authorization selector 232 may select credit card authorizations usinginformation appended by payment processor 164.

In some embodiments, prediction processor 230 may implementauthorization selector 232 by executing instructions to create anenvironment in which credit card authorizations are selected. In otherembodiments, however, authorization selector 232 may be a separatedevice or group of devices. In such embodiments, authorization selector232 may include hardware configured to carry out filtering tasks. Forexample, to improve performance and minimize costs, authorizationselector 232 may be an SRAM-based FPGA that functions as authorizationselector 232. Authorization selector 232 may have an architecturedesigned for implementation of specific algorithms. For example,authorization selector 232 may include a Simple Risc Computer (SRC)architecture or other reconfigurable computing system.

Authorization aggregator 234 may determine time intervals and create afrequency table for the intervals. The frequency table may represent thenumber of authorizations that were issued during a time interval for amerchant. Authorization aggregator 234 may create the frequency tableusing time stamps associated with the credit card authorizations. Forexample, authorization aggregator 234 may receive a group of credit cardauthorizations such as shown in Table 1, below, and calculate afrequency table of authorizations using the time intervals presented inTable 2.

TABLE 1 Authorization No. Time Merchant Amount 1458 11:30 A $58 322111:32 A $23 4434 11:45 A $93 6244 12:40 A $11 7985 12:41 A $13 949912:42 A $61 10765 16:40 A $92 12164 16:45 A $24

TABLE 2 Time interval Frequency 11:30-12:00 3 12:30-13:00 2 16:30-17:002

Prediction processor 230 may implement authorization aggregator 234 byexecuting software to create an environment for aggregation of creditcard authorizations. However, in other embodiments authorizationaggregator 234 may include independent hardware with specificarchitectures to improve the efficiency of aggregation or sortingprocesses. For example, authorization aggregator 234 may be a GPU arrayconfigured to sort credit card authorizations. In some embodiments,authorization aggregator 234 may be configured to implement sortingalgorithms such as, for example, radix sort. Alternatively oradditionally, authorization aggregator 234 may be configured toimplement a programming interface, such as Apache Spark, and executedata structures, cluster managers, and/or distributed storage systems.For example, authorization aggregator 234 may include a resilientdistributed dataset that is manipulated with a standalone softwareframework and/or a distributed file system.

Prediction engine 236 may calculate a prediction indication based on oneor more models and a selected credit card authorization data set. Forexample, prediction engine 236 may use a model from model generator 120and apply inputs based on a posted transaction array to generate aprediction list of hours of operation for merchant 160.

Prediction engine 236 may be implemented by prediction processor 230.For example, prediction processor 230 may execute software to create anenvironment to execute models. However, in other embodiments predictionengine 236 may include hardware configured to carry out paralleloperations. Some hardware configurations improve the efficiency ofcalculations, particularly when multiple calculations are beingprocessed in parallel. For example, prediction engine 236 may includemulticore processors or computer clusters to divide tasks and quicklyperform calculations. In some embodiments, prediction engine may receivea plurality of models from model generator 120. In such embodiments,prediction engine 236 may include a scheduling module. The schedulingmodule may receive models and assign each model to independentprocessors or cores. In other embodiments, prediction engine 236 may beFPGA Arrays to provide greater performance and determinism.

The components of prediction system 110 may be implemented in hardware,software, or a combination of both, as will be apparent to those skilledin the art. For example, although one or more components of predictionsystem 110 may be implemented as computer processing instructionsembodied in computer software, all or a portion of the functionality ofprediction system 110 may be implemented in dedicated hardware. Forinstance, groups of GPUs and/or FPGAs maybe used to quickly analyze datain prediction processor 230.

FIG. 3 is a block diagram of an exemplary model generator, in accordancewith disclosed embodiments. Model generator 120 may include trainingdata module 330, a model processor 340, a model memory 350, and acommunication device 360.

One of the fundamental challenges in obtaining accuratehours-of-operation predictions based on credit card authorization datais the lack of sufficient training data sets. Training sets are sets ofdata used to discover potentially predictive relationships. They mayinclude an input vector and an answer vector, that are used together totrain an AI machine or a knowledge database. A training data set mayonly be sufficient when it includes a number of samples that enables anartificial intelligence machine or a regression model to be “trained”(e.g., initialized) with an acceptable confidence interval. Sufficienttraining data sets may include samples that represent the fulldistribution to be modeled and have enough samples to identify outliersand minimize deviations. In some embodiments, training data sets includea validation subset and a test subset. In such embodiments, each one ofthe subsets must include a representative sample size.

In some embodiments, training data sets associate credit cardauthorizations with ground truth hours of operation, that is, actualhours of operation information as specified by merchants and obtaineddirectly or indirectly from the merchants. Training data sets mayinclude information of brick and mortar merchants with “open” and“closed” hours, permanently closed merchants as negative controls (e.g.,merchants that changed locations), and permanently open merchants aspositive controls (e.g., online retailers). While collecting credit cardauthorization information issued by merchants 160 can be done byretrieving information from databases 180 or financial services 130,there is no central source for ground truth of the hours of operation ofmerchants 160. In some embodiments model generator 120 may include atraining data module 330 that monitors network 170 and online resources140 to capture ground truth and facilitate generating the training dataset. Training data module 330 may combine and select information togenerate the training data sets used to generate prediction models.

Training data module 330 includes an event detector 310, ground truthanalyzer 320, and training filter 332.

Event detector 310 may be a software or hardware module configured todetect events in network 170 that may be relevant to model generator120. In some embodiments, event detector 310 may be configured to detectwhen merchants 160 issue a credit card authorization. In suchembodiments, event detector 310 may signal model generator 120 torequest the authorization information and build the training data set.In addition, event detector 310 may be configured to detect changes inonline resources 140. For example, online resources 140 may include websites operated by merchants 160. If the website is updated, eventdetector 310 may detect changes and request that ground truth analyzer320 investigate the changes and update records. Event detector 310 maycreate a system to automatically update a training data set of hours ofoperation. Event detector 310 may detect merchants 160 that are activelyissuing credit cards, and may have the ability to monitor changes ofground truth to automatically generate a training data set.

Merchant hours of operation are dynamic; that is, businesses changetheir hours of operation, and temporarily or permanently open or closenew locations. Event detector 310 may facilitate updating databases tokeep up-to-date information by monitoring the network 170 and flaggingtransactions that can be used in the training data set.

Ground truth analyzer 320 may include software or hardware modulesconfigured to collect and organize data that is associated withmerchants 160. For example, ground truth analyzer 320 may be configuredto collect hours of operation from online resources 140. Ground truthanalyzer 320 may collect information using a “bot,” such as a webscraper, to automatically fetch and extract information from websitessuch as Yellowpages.com™, Google™, or Yelp™. In some embodiments, groundtruth analyzer 320 may download source code of web pages and parse,search, reformat, and copy data. Ground truth analyzer 320 may sortinformation to select information about merchants 160.

In some embodiments, ground truth analyzer 320 may use text patternmatching, html parsing, vertical aggregation, or semantic annotationrecognizing, among other processes. Ground truth analyzer 320 mayinclude tools to look for hours of operation. For example, in someembodiments a web scraper may be configured to look for text formats of“XX:XX-XX:XX” where X is a digit. In other embodiments, a web scrapermay be configured to recognize labels in html code such as “<timeitemprop=“openingHours”>, “<datetime=“Tu,Th 13:00-20:00”>,” or “<p>Open:Monday-Thursday 9 am-noon</p>.”

In other embodiments ground truth analyzer 320 may include crowd-sourcedservices to obtain information about a merchant. In yet otherembodiments, ground truth analyzer 320 may include a verificationservice that uses phone calls to retrieve information. For exampleground truth analyzer 320 may include an automated calling service thatcalls merchants phone numbers. In such embodiments, ground truthanalyzer 320 may determine whether the merchant is open or closed basedon the phone call response. For example, ground truth analyzer 320 mayinclude auto dialer software that calls merchants. Ground truth analyzer320 may determine that the businesses are open any time merchants 160pick up the phone but assume merchants 160 are closed if there is noanswer.

Training data module 330 may include software or hardware modulesconfigured to create a training data set. Training data module 330 maycreate the training data set by combining credit card authorizationsfrom a group of merchants and ground truth information for the samegroup of merchants. For example, communication device 360 may receive acollection of credit card authorizations generated by a group ofmerchants. If ground truth analyzer 320 has identified hours ofoperation about the same group of merchants, training data module 330may combine these data sets to create a training data set that includescredit card authorizations and ground truth for a group of merchants.

Model processor 340 may include a processor similar to predictionprocessor 230. Model processor may include a data normalizer 342, atraining data filter 344, and accuracy estimator 348, and a modelbuilder 346.

Data normalizer 342 may include hardware or software modules configuredto normalize information under certain parameters. For example, datanormalizer 342 may normalize time stamps by setting them in the samelocal time zone or to UTC time. Alternatively, data normalizer 342 mayadjust time stamps based on a Zip Code™ associated with a merchant thatissued a credit card authorization request.

Training data filter 344 may have a similar configuration toauthorization selector 232 but instead of filtering credit cardauthorizations associated with merchants 160, training data filter 344may select a training data subset before it is used to generate models.The accuracy of the model used to predict hours may vary significantlywhen different data sets are used. For example, predicting hours ofoperation of a restaurant using a training data set that is based ongrocery stores may undermine the prediction's accuracy. For this reason,training data filter 344 may be configured to select training data setsbased on, for example, the category of the merchant in client devices150 requests. Then, the training data set may be constrained to certaintypes of credit card authorizations or models.

Model builder 346 may be software or hardware configured to createprediction models based on the training data. In some embodiments, modelbuilder 346 may generate decision trees. For example, model builder 346may take training data to generate nodes, splits, and branches in adecision tree. Model builder 346 may calculate coefficients and hyperparameters of a decision tree based on the training data set. In otherembodiments, model builder 346 may use Bayesian algorithms or clusteringalgorithms to generate predicting models. In yet other embodiments,model builder 346 may use association rule mining, artificial neuralnetworks, and/or deep learning algorithms to develop models. In someembodiments, to improve the efficiency of the model generation, modelbuilder 346 may be hardware configured to generate models for hours ofoperation. For example, model builder 346 may be an FPGA.

Accuracy estimator 348 may be software or hardware configured toevaluate the accuracy of a model. For example, accuracy estimator mayestimate the accuracy of a model, generated by model build 346, by usinga validation dataset. In some embodiments, the validation data set is aportion of the training data set, that was not used to generate theprediction model. Accuracy estimator may generate error rates for eachone of the prediction models. Accuracy estimator 348 may additionallyassign weight coefficients to models based on the estimated accuracy.

FIG. 4 is a block diagram of an exemplary database 180, in accordancewith disclosed embodiments. Database 180 may include a communicationdevice 402, one or more database processors 404, and database memory 410including one or more database programs 412 and data 414.

In some embodiments, databases 180 may take the form of servers, generalpurpose computers, mainframe computers, or any combination of thesecomponents. Other implementations consistent with disclosed embodimentsare possible as well.

Communication device 402 may be configured to communicate with one ormore components of system 100, such as merchants 160, prediction system110, model generator 120, and/or financial services 130. In particular,communication device 402 may be configured to provide to the predictionsystem 110 and model generator 120 data associated with a number ofmerchants.

Communication device 402 may be configured to communicate with othercomponents as well, including, for example, one or more merchant paymentsystems, such as merchant payment system 166 described above, and one ormore financial services 130 and/or online resources 140. Communicationdevice 402 may take any of the forms described above for communicationdevice 210.

Database processors 404, database memory 410, database programs 412, anddata 414 may take any of the forms described above for predictionprocessors 230, memory 220, prediction programs 222, and prediction data224, respectively. The components of databases 180 may be implemented inhardware, software, or a combination of both hardware and software, aswill be apparent to those skilled in the art. For example, although oneor more components of databases 180 may be implemented as computerprocessing instruction modules, all or a portion of the functionality ofdatabases 180 may be implemented instead in dedicated electronicshardware.

Data 414 may be data associated with a number of merchants, such asmerchant(s) 160. Data 414 may include, for example, credit cardauthorization data. Data 414 may describe purchases made by customers atmerchants using financial cards.

FIG. 5 is a block diagram of an exemplary client device, in accordancewith disclosed embodiments. In one embodiment, client devices 150 mayinclude one or more processors 502, one or more input/output (I/O)devices 504, and one or more memories 510. In some embodiments, clientdevices 150 may take the form of mobile computing devices such assmartphones or tablets, general purpose computers, or any combination ofthese components. Alternatively, client devices 150 (or systemsincluding client devices 150) may be configured as a particularapparatus, embedded system, dedicated circuit, and the like based on thestorage, execution, and/or implementation of the software instructionsthat perform one or more operations consistent with the disclosedembodiments. According to some embodiments, client devices 150 maycomprise web browsers or similar computing devices that access web siteconsistent with disclosed embodiments.

Processor 502 may include one or more known processing devices, such asmobile device microprocessors manufactured by Intel™, NVIDIA™, orvarious processors from other manufacturers. The disclosed embodimentsare not limited to any specific type of processor configured in clientdevices 150.

Memory 510 may include one or more storage devices configured to storeinstructions used by processor 502 to perform functions related todisclosed embodiments. For example, memory 510 may be configured withone or more software instructions, such as programs 512 that may performone or more operations when executed by processor 502. The disclosedembodiments are not limited to separate programs or computers configuredto perform dedicated tasks. For example, memory 510 may include a singleprogram 302 that performs the functions of the client devices 150, orprogram 312 may comprise multiple programs. Memory 510 may also storedata 314 that is used by one or more programs 312.

In certain embodiments, memory 510 may store an hours-of-operationapplication 514 that may be executed by processor(s) 502 to perform oneor more prediction processes consistent with disclosed embodiments. Incertain aspects, hours-of-operation application 514, or another softwarecomponent, may be configured to request predictions from predictionsystem 110 or determine the location of client devices 150. Forinstance, these software instructions, when executed by processor(s) 502may process information to generate a request for hours of operation.

I/O devices 504 may include one or more devices configured to allow datato be received and/or transmitted by client devices 150 and to allowclient devices 150 to communicate with other machines and devices, suchas other components of system 100. For example, I/O devices 504 mayinclude a screen for displaying optical payment methods such as QuickResponse Codes (QR), or providing information to the user. I/O devices504 may also include components for NFC communication. I/O devices 504may also include one or more digital and/or analog devices that allow auser to interact with client devices 150 such as a touch-sensitive area,buttons, or microphones. I/O devices 504 may also include one or moreaccelerometers to detect the orientation and inertia of client devices150. I/O devices 504 may also include other components known in the artfor interacting with prediction system 110, merchants 160, and/orfinancial services 130.

The components of client devices 150 may be implemented in hardware,software, or a combination of both hardware and software, as will beapparent to those skilled in the art.

FIG. 6 is an exemplary flow chart illustrating a prediction process, inaccordance with disclosed embodiments. In some embodiments, predictionprocess 600 may be executed by prediction system 110.

Prediction system 110 may receive requests for hours of operation fromclient devices 150, or other components of system 100, in step 602.These requests may come in the form of an internet protocol message, aquery data packet, or a port opening instruction, and may furtherinclude information of client devices 150 and specify one or moremerchants 160. For example, the requests may specify name and/oridentification number of merchants 160. The requests may also specify aday of the week to be used as a parameter to predict opening and closingtimes and/or a location associated with the client devices 150 andmerchants 160.

In step 604 prediction system 110 may obtain credit card authorizationsassociated with the one or more merchants 160 specified in the requests.For example, prediction system 110 may query databases 180 to obtain allthe credit card transactions that have been issued by the merchants 160associated with the requests. In some embodiments, prediction system 110may limit the query to a subset of the credit card authorizations issuedby merchants 160. For example, prediction system 110 may request onlycredit card authorizations that have been issued for a specific day.Also, prediction system 110 may request credit card authorizationsissued in the last year, in the last month, or between two dates.

In step 606, prediction system 110 may filter, or select, a portion ofthe data received from the database based on information contained inthe received requests. For example, in embodiments where predictionsystem 110 retrieves all credit card authorizations issued by amerchant, prediction system 110 may select credit card authorizationsissued on the day of the week specified in the request. In otherapplications, prediction system 110 may select only credit cardauthorizations above certain dollar amount. In yet other applications,prediction system 110 may receive a set of credit card authorizationsand determine a subset of credit card authorizations based on therequests. For example, prediction system 110 may determine a subset ofcredit card authorizations based on day of the week specified by therequest.

In some embodiments, prediction system 110 may filter the credit cardauthorization data retrieved from databases 180 to simplify futureanalysis. In such embodiments, authorization selector 232 may curate andclassify credit card data authorizations. For example, authorizationselector 232 may use information from the requests issued by clientdevices 150 to create a subset of credit card authorizations.Authorization selector 232 may use information associated with creditcard authorizations to select or discard authorizations. For example,authorization selector 232 may discard authorizations that are notgenerated in within the specified day of the week. Also, authorizationselector 232 may remove transactions considered abnormal. For example,authorization selector 232 may disregard authorizations that have adollar amount significantly different from the other authorizations.Such authorizations may represent credit card activity that is notrelated with hours of operation. For example, a merchant that wholesalesto other businesses may make large sales after hours to a selecteddistributor while the merchant is not being open to the public. Thosetransactions that do not correlate with hours of operation may befiltered based on transaction amount or other related parameters.

In some embodiments prediction system 110 and authorization selector 232may use data-mining algorithms to efficiently curate, parse, and/orfilter the credit card authorizations. For example, prediction system110 may use algorithms such as C4.5, Support Vector Machines, Apriorialgorithm, Expectation-maximization algorithm, among others, to handlelarge data sets of credit card authorizations.

In step 610 prediction system 110 may determine a total number ofauthorizations for the selected day authorizations subset. In someembodiments, prediction system 110 may aggregate the number ofauthorizations to determine a total number of authorizations for thespecified day of the week.

In step 612, prediction system 110 may determine whether the quantity ofcredit card authorizations is sufficient to make an accurate prediction.In some embodiments, prediction system 110 may determine a thresholdnumber of transactions over a period of time. For example, predictionsystem 110 may set a threshold of 50 transactions over a 5 month period.If the threshold is not met, then prediction system 110 may determinethat the quantity of authorizations is insufficient. In otherembodiments, prediction system 110 may determine that the quantity ofcredit card authorizations is not sufficient if the oldest record isless than 5 months old. In yet other embodiments, prediction system 110may determine the quantity is not sufficient if a requested predictionaccuracy cannot be met with the available records. For example, clientdevices 150 may request a minimum prediction accuracy of 90%. Predictionsystem 110 may determine a minimum quantity of credit cardauthorizations required to achieve the requested prediction accuracy. Ifthe available quantity of credit card authorizations is less than thedetermined minimum, prediction system 110 may return an error messagereporting that there are not enough records to make the prediction.

If prediction system 110 determines that there is not enough data,process 600 continues to step 614 in which the prediction system mayreturn an error message. In some embodiments, the error message may besent to online resources 140 which then may send a message to clientdevices 150. In such embodiments, online resources 140 may transmitdefault values for hours of operation to client devices 150 or simplynot send any data for hours of operation. Additionally or alternatively,prediction system 110 may send the error message to merchants 160 toindicate that potential customers cannot access hours of operation.Alternatively, if prediction system 110 determines that there is enoughdata, it continues to step 616.

In step 616, prediction system 110 determines time intervals for thehours of operation analysis, for example, 30 minutes. In someembodiments, the time intervals may be determined based on aclassification for merchant 160. In other embodiments, the timeintervals may be based on the requests for information. In yet otherembodiments, prediction system 110 may determine time intervals based ontime rules.

Time rules may instruct prediction system 110 to determine timeintervals with equal time length that do not overlap each other. Also,time rules may instruct prediction system 110 to have time intervalswherein the sum of time lengths equals one day. Time rules mayadditionally instruct prediction system 110 to determine time intervalsof 30 minutes. For example a full day may be divided in 48 timeintervals of half an hour. Half hour time intervals facilitate theprediction process as they match with standard business hours.Alternatively, time rules may instruct prediction system 110 todetermine time intervals of other or varying length and that may or maynot overlap with each other.

In step 618, prediction system 618 may generate a posted transactionsarray. The posted transaction array may associate the determined timeintervals with an aggregated number of transactions. For example,authorization aggregator 234 may utilize the plurality of times togenerate an array that indicates how many transactions were recorded fora given time period.

In some embodiments, prediction system 110 may adjust the postedtransactions array based on the total number of authorizations for theselected day. For example, authorization aggregator 234 may normalizethe number of aggregated authorizations using the total number oftransactions. In such embodiments, prediction system 110 may use thetotal number of authorizations to prevent over reliance in a singlemerchant. Using the absolute number of transactions to create predictionmodels may result in a model dominated by large merchants that post manytransactions. Such models may be inaccurate when predicting hours ofoperation of smaller merchants or may result in models that have pooradaptation. Thus, prediction system 110 may adjust the postedtransactions using the total number of authorizations to smooth theeffect of large merchants with many transactions and extract patternsthat are insensitive to absolute volume of transactions (e.g.,normalizing).

In step 620, prediction system 110 generates a prediction list. In someembodiments, prediction system 110 generates the prediction list bydetermining, for each one of the time intervals in the postedtransaction array, prediction probabilities. The predictionprobabilities may be calculated using prediction models from modelgenerator 120. Each prediction model may output a model result, whichmay be a probability between 0-100%.

Step 620 may be carried out by prediction engine 236. Prediction enginemay compute a probability of a merchant being open or closed. Forexample, in step 620 prediction system 110 may request from modelgenerator 120 one or more models to predict hours of operation for aselected merchant. Prediction system 110 may then send prediction modelsand credit card authorization data to prediction engine 236 to performthe probability calculations.

In some embodiments, prediction engine 236 may receive a plurality ofmodels from model generator 120 and compute probabilities independentlyfor each one of the models. Prediction engine 236 may then tally eachone of the prediction model results. In such embodiments, predictionengine 236 may determine an accuracy value for each model and each modelresult. For example, based on the evaluation performed by accuracyestimator 348, prediction engine 236 may determine an accuracy value foreach model and each model result. Then prediction engine 236 may assignweighting coefficients to the models based on the accuracy values. Insuch embodiments, prediction engine 236 may modify the computedprobability for each one of the models (i.e. the model results) usingthe assigned weighting coefficient to calculate a total prediction. Forexample, total prediction may be defined by:

${TotalPrediction} = \frac{\sum\limits_{i = 0}^{j}{\alpha_{i}*{MR}_{i}}}{N}$

where TotalPrediction is the value to be stored in the prediction list,j is the total number of models retrieved from model generator 120, α isthe assigned coefficient (which is a function of the determineaccuracy), and MR is the model result for one prediction model, and N isa normalization value. Thus, prediction engine 236 may add modified treeresults to determine a total prediction. The total prediction may beused to determine a prediction indication, such as “open” or “closed.”

In step 622, prediction system 110 may communicate the results list tothe client that issued the request. For example, prediction system 110may communicate the request with a list of Boolean values indicatingwhether the merchant is open or closed during each half-hour interval ofthe day for the day of the week as specified in the original request.

FIG. 7 is an exemplary flow chart illustrating a prediction listgeneration process, in accordance with disclosed embodiments. Predictionlist generation process 700 may be carried out by prediction system 110.

In step 702, prediction system 110 may determine whether there is aclassification associated with the merchant. For example, predictionsystem 110 may determine if the merchant to be analyzed is a restaurant,a grocery store, a bar, etc. It may do so using the credit cardauthorization data retrieved from the databases 180. For example, insome embodiments prediction system 110 may use Federal IdentificationCodes (FIC) in the credit card authorization requests to determine amerchant classification.

In step 704, prediction system 110 may obtain a model for the merchant.In some embodiments, prediction system 110 may send a request to modelgenerator 120 to generate prediction models for the merchant. Modelgenerator 120 may respond with one or more prediction models for themerchant based on, for example, the classification for the merchant andthe day of the week. For instance, model generator 120 may send toprediction system 110 a group of prediction models specifically forrestaurants open on Saturdays.

In step 706, prediction system 110 may prepare to carry out an iterativecalculation to estimate a prediction indication for each one of the timeintervals. The status of the looping variable is then tested in step708. If the looping variable indicates the iterative process isculminated, prediction system 110 may send the prediction list to theclient in step 710. Alternatively, if the looping variable indicates theiterative process is not culminated, prediction system 110 may continueto step 712 and calculate a prediction for a time interval using thegroup of models. To carry out step 712 prediction system 110 may send arequest for calculation to prediction engine 236.

In step 712, prediction system 110 may tally results of predictionmodels as previously disclosed for step 620 and save the estimated totalprediction in a prediction list in step 716. In some embodiments,prediction system 110 may generate a prediction indication based on thetotal prediction value. In some embodiments, the prediction indicationmay be a Boolean value, such as “open” or “closed” value. In otherembodiments, the prediction indication may represent a status associatedwith the total prediction value. For example, the prediction indicationmay be “likely open,” “likely closed,” “out of business,” or “24/7open.”

In step 718, prediction system 110 may modify the looping variable tocontinue the iterations.

FIG. 8 is an exemplary flow chart illustrating a posted transactionarray generation process, in accordance with disclosed embodiments.Posted transaction array generation process 800 may be carried out byprediction system 110.

In step 802, prediction system 110 may adjust information in the creditcard authorizations. For example, in some embodiments the credit cardauthorizations may comprise time stamps. In such embodiments, predictionsystem 110 may adjust the time stamps in credit card authorizationsbased on a location code associated with merchants 160 to facilitategenerating the prediction list. For example, a credit card authorizationsystem may always record time stamps in Eastern Standard Time,regardless of merchant's 160 location. Then prediction system 110 mayadjust the time stamp of the credit card authorization based on alocation code associated with the merchant. For example, predictionsystem 110 may adjust time stamps using the Zip Codes™ of merchants 160.

In step 804, prediction system 110 may associate the credit cardauthorization with a time interval. In some embodiments, predictionsystem 110 may sort credit card authorizations using the time stampassociated with the credit card authorizations. In such embodiments,prediction system 110 may utilize sorting algorithms to process data andobtain the categories that associate time intervals and the credit cardauthorizations.

In step 806, prediction system 110 may aggregate the number ofauthorizations issued within the time intervals to generate a frequencytable that quantifies the number of times a credit card authorizationwas issued for in a time interval.

In step 808, prediction system 110 may generate a posted transactionarray using the information of the number of authorizations and data.

FIG. 9 is an exemplary flow chart illustrating a model generationprocess, in accordance with disclosed embodiments. In some embodiments,model generator 120 may carry out model generator process 900.

In step 902, model generator 120 may receive a request for predictionmodels. In some embodiments, the request may specify a merchant, a timeof the day, and/or a merchant classification. For example, predictionsystem 110 may send a request for prediction models. The request mayinclude information about merchants 160 and/or client devices 150.

In step 904, model generator 120 may generate a training data set. Modelgenerator 120 may generate the training data set using information fromdatabases 180, online resources 140, and/or financial services 130. Forexample, model generator 120 may retrieve, from databases 180, creditcard authorizations associated with a group of merchants 160. Modelgenerator 120 may also collect a ground truth data set, from the groundtruth analyzer 320, associated with the same group of merchants.Training data module 330 may merge or combine these data sets togenerate a training data set. In some embodiments, training data module330 may be configured to rate the accuracy of information in the dataset. For example, training data module 330 may create ground truthaccuracy scores for merchants 160. When ground truth analyzer is highlyconfident of hours of operation for merchants 160, for example groundtruth analyzer verified the determined hours of operation on a websiteof merchants 160, then training data module 330 may assign a high groundtruth accuracy score. Alternatively, if ground truth analyzer 320 is notconfident of hours of operation, for example hours of operation wereguessed based on phone calls responded, then training data module 330may assign a low score. Ground truth accuracy scores may enableincluding more merchants 160 in the training data set. Even if theground truth information is not verified for a group of merchants 160,training data module 330 may still include those merchants and tailorthe model's reliance on those samples with the ground truth accuracyscore.

In some embodiments, model generator 120 may generate input modelfeatures based on credit card authorizations associated with a group ofmerchants 160. Model features may represent a variable useful forprediction that may be used in the prediction solution. For example,model features may include the number of credit card authorizationsissued by merchants 160 within a period, a location associated with thecredit card authorizations, or a merchant type. In certain embodiments,model generator 120 may generate multiple model features and determine afeature importance score for all the generated features. The featureimportance score may reflect the correlation between the selectedfeatures and other identified features. For example, model generator 120may assign a high importance score to a variable or feature thatexhibits a high correlation with the other identified features.Alternatively, a feature with low correlation with respect to otherfeatures may be assigned a low importance score. Furthermore, inadditional or alternative embodiments, the model features may becategorized based in the influence they have in the target result. Insome embodiments, the input model features may then be used to determinea model. For example, in a decision tree input model features may beused to make node determinations.

In some embodiments, model generator 120 may generate model featuresusing techniques such as Principal Component analysis and/orunsupervised clustering methods. In other embodiments model generator120 may include line or edge detection, or Digital Signal Processing(DSP) methods. In such embodiments, model generator 120 may implementiterative regressions to evaluate features. For example, model generator120 may execute algorithms such as least absolute shrinkage andselection operator to determine least squares models for each generatedfeature to estimate a feature behavior.

In some embodiments, training data module 330 may select data based onthe request for a prediction model of step 902. For example, predictionsystem 110 may request a model from model generator 120 for a restauranton Saturday. Training data module 330 may generate a training data setonly using credit card authorization and ground truth only forrestaurants on Saturdays.

In step 906, model generator 120 may create training data subsets bydividing the training data set. In some embodiments, model generator 120may divide the training data set randomly creating random trainingsubsets. Then, prediction models may be generated using the randomlyselected subsets of the training data set. Elements in the training datasubsets may be unique to each subset to create independent training datasubsets. Alternatively, training data subsets may share elements andoverlap. In other embodiments, model generator 120 may divide thetraining data set using division rules.

The training data set division rules may indicate the number ofdivisions and/or ratios between different groups. For example, thetraining data set may be divided using an 80/20 split for testing andvalidation data. Training data division rules may also specify thetraining data set should be divided in three portions. A first portionto calculate coefficients for a model, a second portion used tocalculate hyper parameters associated with a model, and a third portionused to validate and calculate accuracy of the model. Division rules maybe a function of the information included in the request for aprediction model. For example, if the request specifies the model is fora restaurant, model generator 120 may apply a 60/40 split for testingand validation to have stricter accuracy measurements.

Model generator 120 may generate a candidate model using a training dataset. For example, model generator may process the training data set ofstep 906 to determine coefficients (step 908) and hyper parameters (step910) for a prediction model. The prediction models may be parametric,non-parametric, or semi-parametric.

In some embodiments, model generator 120 may create a plurality ofdecision trees as prediction models. For example, model generator 120may use a top-down or a bottom-up approach to generate candidatedecision trees in steps 908 and 910. In such embodiments, modelgenerator 120 may generate nodes by finding a discrete function of theinput attributes values using a training data set or a training datasubset. Based on a splitting metric, a coefficient may be assigned tothe node. Decision trees created by model generator 120 may then be usedin a random forest analysis.

In other embodiments, model generator 120 may generate neural networks,Group Method of Data Handling (GMDH) algorithms, Naive Bayesclassifiers, and/or Multivariate Adaptive Regression Splines. Forexample, model generator 120 may implement Convolutional Neural Networks(CNN), generating nodes and connections associated with multipledimensions using the training data. CNNs consist of multiple layers ofreceptive fields and various combinations of convolutional and fullyconnected layers. Additionally, model generator 120 may implementRecurrent Neural Networks (RNN), generating nodes and connections withdirected cycles that dynamically adjust to behaviors of the trainingdata.

In some embodiments, model generator 120 may generate candidate modelsunder defined constraints. For example, in embodiments in which thegenerated models are decision trees, model generator 120 may beconstrained to have a maximum depth of 10 node levels.

In step 914, model generator 120 may evaluate if the model is completedor if it has reached a stopping criteria. For example, when modelgenerator 120 generates decision trees, in step 914 model generator 120may evaluate if a stopping criteria is fulfilled for the end nodes. Insome embodiments, stopping criteria may be intrinsic to the model ordefined by hyper parameters. For example, the stopping criteria may beachieved when all the samples there is no further classifications orvariables to further split the model. Alternatively, the stoppingcriteria may be defined by user imposed constrains and hyper variables.

If the stop criteria in not fulfilled, model generator 120 may continueto step 916 and select a new variables or parameters to determine newclassifiers. In embodiments in which model generator 120 generates adecision tree, in step 916 model generator 120 may select a new functionfor splitting a subset of the training data set after the first split inthe root node. If the splitting results are above a splitting ratio thenmodel generator 120 may include a new node in the decision tree. Inother embodiments, model generator 120 may continue adding nodes ormodes to the model in step 916. After developing the model, modelgenerator 120 may return to step 914 and evaluate again if the model iscompleted.

Alternatively, when the stop criteria is fulfilled, model generator 120may continue to step 918, in which model generator 120 calculate theaccuracy of the model using a portion of the training data set. Modelgenerator 120 may use, for example, information gain, Gini index,likelihood-ratio chi-square statistics, Dietterich Kearns, and Mansour(DKM) splitting criterion, and/or normalized impurity based criteria toevaluate accuracy of the generated model. In some embodiments, modelgenerator 120 may also generate a receiver operating characteristiccurve to evaluate the performance of a binary classifier.

In step 920, model generator 120 may evaluate whether the accuracy forthe model is above an accuracy threshold. In some embodiments, theaccuracy threshold for the model may be automatically adjusted based onoptimization objectives set for the prediction models. If the model isnot above the threshold (step 920: No) the model may be discarded instep 926. If the calculated accuracy is above the threshold (step 920:Yes), model generator 120 may assign a weighted coefficient to the modelin step 922 and include the model to the set of models in step 924. Theweighted coefficient may associated with the calculated accuracy. Forexample, the weighted coefficient may be proportional to the accuracy.

Process 900 may be repeated a plurality of times to generate a pluralityof models. In some embodiments, model generator 120 may repeat theprocess until a minimum of models is generated. For example, predictionsystem 110 may request that model generator 120 generates models for arandom forest analysis. In such embodiments, model generator 120 maygenerate between 20-100 decision trees to conduct the predictionanalysis. Less than 20 models may not provide the required accuracywhile more than a 100 decision trees may demand too much computingpower. In such embodiments, prediction system may require at least 50decision trees.

FIG. 10A is an exemplary posted transaction array 1010, in accordancewith disclosed embodiments. Prediction system 110 may generate postedtransaction array 1010 in, for example, step 618 of FIG. 6. Postedtransaction array 1010 may be issued by authorization aggregator 234,and may associate time intervals 1012 with aggregated number ofauthorizations 1014.

Time intervals 1012 may have a start time and an end time, may bedetermined by prediction system 110, and may have different formats.While FIG. 10A shows independent and sequential time intervals, timeintervals need not be sequential or independent. For example, timeintervals may overlap, or may be non-consecutive.

Aggregated number of authorizations 1014 may indicate the total numberof authorizations that were issued by a merchant during the timeinterval. Prediction system 110 may generate a frequency table by addingthe number of credit card transactions for each time interval.

FIG. 10B is an exemplary prediction list 1020, in accordance withdisclosed embodiments. In some embodiments prediction list 1020 may begenerated by prediction system 110, for example, at step 620. In suchembodiments prediction list 1020 may be generated by prediction engine236. Prediction list 1020 may associate time intervals 1022 with aprediction indication 1024.

Prediction time intervals 1022 may be based on transaction time interval1012. In some embodiments, prediction time intervals 1022 may replicatetransaction time intervals 1012. In other embodiments, prediction timeinterval 1022 may be a subset of transaction time intervals. Forexample, some prediction time intervals may group two or moretransaction time intervals if they a have similar number ofauthorizations 1014 to facilitate plotting an minimizing transmissiontime.

Prediction list 1020 may include prediction indications 1024. In someembodiments, prediction indications 1024 may be Boolean and indicatewhether the prediction model calculates the merchant to be open orclosed. In other embodiments, however, prediction indication 1024 may bea category associated with the prediction probability. For example,prediction indication 1024 may assign a label such as “likely open,”“likely closed,” “out of business,” or “24/7 open.”

Prediction list 1020 may include probability values 1026. Probabilityindications 1026 may represent a calculated prediction probability forthe merchant being open at the time intervals. Alternatively,probability indications 1026 may represent a calculated predictionprobability for the merchant being closed at the time intervals.Probability indications 1026 may be based on the model results that areestimated in step 714.

FIG. 11 is a graph of an exemplary prediction accuracy calculation as afunction of a time interval, in accordance with disclosed embodiments.Information presented in FIG. 11 may be generated by model generator 120at, for example, step 918.

FIG. 11 presents a plot in which the x-axis presets a time interval, forexample time intervals 1012 (FIG. 10), and the y-axis represent anaccuracy estimation. The accuracy estimation may calculate accuracy ofthe model using the a training data subset. The accuracy calculation maybe performed for each one of the time intervals. In some embodiments,accuracy may represent the ratio of correct predictions to the totalnumber of cases evaluated. In other embodiments, accuracy may representthe area under the curve of receiver operating characteristic (ROC)curve. In yet other embodiments, accuracy may represent a positivepredictive value or a sensitivity for a specific criterion value or agroup of criterion values. For example, accuracy may be the positivepredictive value for an optimal criterion based on costs.

FIG. 12 shows graphs of two exemplary comparative results, presenting aground truth and a prediction as a function of a time interval forcontrol merchants, according with disclosed embodiments. The comparativeresults are presented in plots where the X axis represents a timeinterval, for example time intervals 1022 (FIG. 10), and the Y axisrepresents a predicted probability of the merchant being open (for theprediction solid line) and the hours of operation ground truth (dottedline).

Example 1 shows results for a negative control. Merchant in Example 1 isnever open. For example, the merchant in Example 1 may be a closedbusiness. Therefore the ground truth plot shows that the merchant isalways closed. In Example 1, the prediction, calculated by predictionsystem 110 using credit card authorization data, is always low. InExample 1, because the merchant is closed, the merchant does not issueany credit card authorizations. Therefore prediction system 110generates a prediction list with low probabilities for all timeintervals.

Example 2 shows results for a positive control. The merchant in example2 is always open. For example, the merchant in Example 1 is an onlinebusiness that does not close and continuously receives orders and issuescredit card authorizations. Therefore the ground truth plot shows thatthe merchant is always open. In Example 1, the prediction is alwayshigh. In Example 2, the merchant constantly receives orders and issuescredit card authorizations. Therefore, prediction system 110 generates aprediction list with high probabilities for all time intervals.

FIG. 13 shows graphs of exemplary comparative results presenting aground truth and a prediction as a function of a time interval fortesting merchants, according with disclosed embodiments. FIG. 13presents plots similar to the ones in FIG. 12 with the same coordinateaxes. Examples 3-6 show predicted and ground truth hours of operationfor four different merchants.

Merchants of Examples 3-6 open and close within a day. The dotted linerepresent the ground truth of hours of operation while the solid linerepresent the prediction probability of the merchant being open orclosed. Examples in FIG. 13 show that the prediction generally followsthe hours of operation for each merchant. The prediction is low with themerchant is closed while the prediction is high when the merchant isopen.

In some embodiments the prediction can be further classified in a binarystate. For example in some embodiments, prediction system 110 maydetermine any prediction probability above 50% is open while anyprediction below 50% is closed. In other embodiments prediction system110 may classify in different states. For example predictionprobabilities below 25% may have a status of “closed”, predictionprobabilities between 25-50% may have a status of “likely closed,”prediction probabilities between 50-75% may have a status of “likelyopen,” and prediction probabilities between 75-100% may have a status of“open.”

Another aspect of the disclosure is directed to a non-transitorycomputer-readable medium storing instructions that, when executed, causeone or more processors to perform the methods, as discussed above. Thecomputer-readable medium may include volatile or non-volatile, magnetic,semiconductor, tape, optical, removable, non-removable, or other typesof computer-readable medium or computer-readable storage devices. Forexample, the computer-readable medium may be the storage unit or thememory module having the computer instructions stored thereon, asdisclosed. In some embodiments, the computer-readable medium may be adisc or a flash drive having the computer instructions stored thereon.

It will be apparent to those skilled in the art that variousmodifications and variations can be made to the disclosed remote controlsystem and related methods. Other embodiments will be apparent to thoseskilled in the art from consideration of the specification and practiceof the disclosed remote control system and related methods. It isintended that the specification and examples be considered as exemplaryonly, with a true scope being indicated by the following claims andtheir equivalents

1-20. (canceled)
 21. An artificial intelligence system for generating anhours-of-operation model, the system comprising: a processor incommunication with a prediction system and a database; and a storagemedium storing instructions that, when executed, configure the processorto: receive, from a prediction system, a request for anhours-of-operation model for merchants; determine a merchantclassification based on metadata associated with the merchants; obtain,from a ground truth analyzer, ground-truth data associated with themerchant classification; obtain, from the database, a set of credit cardauthorizations associated with the merchant classification; generateinput model features based on the set of credit card authorizations;generate a training data set and a validation data set based on theground-truth data and the set of credit card authorizations; determinean hours-of-operation model based on training data set and the inputmodel features; determine a performance of the hours-of-operation modelbased on the validation data set; and communicate the hours-of-operationmodel for the merchant to the prediction system.
 22. The artificialintelligence system of claim 21, wherein the instructions that configurethe processor further comprise instructions to, receive, from an eventdetector, an alert that a website has been updated; and request, fromthe ground truth analyzer, updated ground-truth data.
 23. The artificialintelligence system of claim 21, wherein the ground truth analyzercomprises a web scraper configured to record hours of operation fromwebsites.
 24. The artificial intelligence system of claim 21, whereinthe hours-of-operation model comprises nodes, splits, and branches in adecision tree.
 25. The artificial intelligence system of claim 24,wherein the nodes are assigned coefficients based on splitting metrics.26. The artificial intelligence system of claim 24, wherein thehours-of-operation model has a maximum depth of 10 node levels.
 27. Theartificial intelligence system of claim 21, wherein the instructionsthat configure the processor to determine an hours-of-operation modelcomprises instructions that configure the processor to execute a routinein a FPGA.
 28. The artificial intelligence system of claim 21, whereinthe instructions that configure the processor to generate a trainingdata set and a validation data set comprise instructions that configurethe processor to determine a ratio split for testing data set and thevalidation data set based on the merchant classification.
 29. Theartificial intelligence system of claim 21, wherein the instructionsthat configure the processor further comprise instructions to normalizecredit card authorization time stamps by setting them in the same timezone.
 30. The artificial intelligence system of claim 21, wherein theinstructions that configure the processor further comprise instructionsto: determine whether a minimum number of models have been communicatedto the prediction system; and generate a new model when the minimumnumber of models have not been communicated to the prediction system.31. The artificial intelligence system of claim 21, wherein theinstructions that configure the processor to determine the accuracy ofthe hours-of-operation model further comprises instructions thatconfigure the processor to: determine a performance threshold, andcompare the performance threshold and the performance of the model. 32.A non-transitory computer-readable medium storing instructions that,when executed by a processor, cause the processor to operate anartificial intelligence system for generating an hours-of-operationmodel, the instructions comprising: receiving, from a prediction system,a request for an hours-of-operation model for merchants; determining amerchant classification based on metadata associated with the merchants;obtaining, from a ground truth analyzer, ground-truth data associatedwith the merchant classification; obtaining, from the database, a set ofcredit card authorizations associated with the merchant classification;generating input model features based on the set of credit cardauthorizations; generating a training data set and a validation data setbased on the ground-truth data and the set of credit cardauthorizations; determining an hours-of-operation model based ontraining data set and the input model features; determining accuracy ofthe hours-of-operation model based on the validation data set; andcommunicating the hours-of-operation model for the merchant to theprediction system.
 33. The non-transitory computer-readable medium ofclaim 32, wherein the instructions further comprise instructions for:receiving, from an event detector, an alert that a website has beenupdated; and requesting, from the ground truth analyzer, updatedground-truth data.
 34. The non-transitory computer-readable medium ofclaim 32, wherein the ground truth analyzer comprises a web scraperconfigured to record hours of operation from websites.
 35. Thenon-transitory computer-readable medium of claim 32, wherein thehours-of-operation model comprises nodes, splits, and branches in adecision tree.
 36. The non-transitory computer-readable medium of claim32, wherein determining an hours-of-operation model comprises executinga routine in a FPGA.
 37. The non-transitory computer-readable medium ofclaim 32, wherein generating a training data set and a validation dataset comprises determining a ratio split for testing data set and thevalidation data set based on the merchant classification.
 38. Thenon-transitory computer-readable medium of claim 32, wherein theinstructions further comprise instructions for normalizing credit cardauthorization time stamps by setting them in the same time zone.
 39. Thenon-transitory computer-readable medium of claim 12, wherein theinstructions further comprise instructions for: determining whether 20models have been communicated to the prediction system; and generating anew model when 20 models have not been communicated to the predictionsystem.
 40. An artificial intelligence method for generating anhours-of-operation model for a prediction system, the method comprising:receiving, from a prediction system, a request for an hours-of-operationmodel for a merchant; determining a merchant classification for themerchant based on metadata associated with the merchant; obtaining, froma ground truth analyzer, ground-truth data associated with the merchantclassification; obtaining, from the database, a set of credit cardauthorizations associated with the merchant classification; generatinginput model features based on the set of credit card authorizations;generating a training data set and a validation data set based on theground-truth data and the set of credit card authorizations; determiningan hours-of-operation model based on training data set and the inputmodel features; determining a performance of the hours-of-operationmodel based on the validation data set; and communicating thehours-of-operation model for the merchant to the prediction system.